Communications network

ABSTRACT

A service platform in a communications network connects callers to a service resource platform when implementing services requiring specialised resources. A number of different services use a common service resource platform. The service platform is programmed with respective maximum values for the number of calls originating from each service that may be connected to the service resource platform at one time and allows the call to be connected to the service resource platform at one time and allows the call to be connected to the service resource platform only when the count value for the respective service is less than the maximum count value. The service resource platform may have a single network address and a common range of ports that are freely allocated to calls generated by the different services running on the service platform.

[0001] The present invention relates to a communications network, and inparticular to a network employing an IN (intelligent network)architecture.

[0002] In a network employing an IN architecture, basic call processingis carried out by local switching nodes. In the case of anything otherthan basic call processing, control of the call is passed to a serviceplatform, sometimes termed a service control point (SCP). For someservices, such as number translation in the case of an 0800 service, allthe resources required for completing processing of the call may beprovided by the service platform. However, other services require theuse of specialised resources such as, for example, voice interactioncapabilities. These resources are provided by a service resourceplatform termed an intelligent peripheral (IP). Typically, the serviceplatform, at an appropriate point in a call, sends instructions to thelocal switching node to connect one of the parties to the call to theintelligent peripheral. The intelligent peripheral is connected via asignalling interface to the service platform and returns data to theservice platform. This interface, and also the interface between the SCPand the local switching nodes may use INAP (intelligent networkapplication protocol). INAP is an internationally agreed standard forIntelligent Networks. The standard is set out in full in “IntelligentNetwork (IN); Intelligent Network Capability Set 1(CS1); CoreIntelligent Network Application Protocol (INAP)”, EuropeanTelecommunications Standards Institute, pr ETS 300 374-1.

[0003] Sometimes a number of different services may make use of the samespecialised service resources. For example, the use of voice recognitionor DTMF (dual tone multi-frequency) recognition to collect informationfrom a calling party is a feature of several different servicesincluding both inbound calling to call centres, and chargecard services,that is services in which charges are billed to a customer accountrather than to the line originating the call.

[0004] According to a first aspect of the present invention, there isprovided a method of operating a communications network including aplurality of network switches, a service platform connected by asignalling interface to the plurality of network switches, and a serviceresource platform, the method including,

[0005] when a service provisioned for a party to a call requires serviceresources from the platform then, under the control of the serviceplatform, connecting a party to the call via a network switch to theservice resource platform,

[0006] for each of a plurality of different services requiring theservice resources of the service resource platform, maintaining a countof the respective number of ongoing calls connected to the serviceresource platform

[0007] storing for one or more of the plurality of services a maximumcount value and

[0008] connecting a further call to the service resource platform onlywhen the count value for the said service is less than the maximum countvalue.

[0009] This aspect of the present invention removes the need topre-allocate a range of ports on a platform to a particular service,thereby making possible more efficient use of the resources provided bythe platform. This is achieved by allocating resources to differentservices under software control by setting a limit specific to eachservice and admitting calls up to that limit. For example, if theresource platform has the ability to handle up to 2600 simultaneouscalls, and is to be shared between two different services, then oneservice might be allocated a limit of 2000 calls and the other a limitof 600 calls. Preferably the platform has a single network address and aplurality of ports, and a common range of ports are accessed by theplurality of services. In this case, provided a call is admitted, thenit can be freely allocated any unoccupied port on the resource platform.

[0010] Systems embodying the present invention will now be described infurther detail, by way of example only, with reference to theaccompanying drawings, in which:

[0011]FIG. 1 is a schematic of a network embodying the invention;

[0012]FIG. 2 is a diagram showing the architecture of the servicecontrol point and intelligent peripheral of FIG. 1;

[0013]FIG. 3 is a schematic showing the memory channel of FIG. 2;

[0014]FIG. 4 is a diagram showing objects used in implementing theoverload control server and transaction server; and

[0015]FIG. 5 is flow diagram illustrating an alternative embodiment.

[0016] A telecommunications network employing an intelligent network(IN) architecture includes a number of service switching points (SSP's)1 which may be located, for example, at a transit exchange or localexchange. Subscriber terminals 2 are connected, directly or indirectly,to the SSP. The SSP carries out a call control function (CCF) whichcomprises the basic call processes associated with the setting up of aconnection between different terminals on the network. An intelligentperipheral (IP) 3 is connected to one of the service switching points.In this example, the intelligent peripheral is an interactive voiceresponse (IVR) platform equipped to play dialogues to customers and tocollect data from customer responses.

[0017] A service control point (SCP) 5 is connected to the serviceswitching points 1 and the intelligent peripheral 3 via a signallingnetwork 4. This network uses a digital message-based common channelsignalling system known as Signalling System No. 7 (SS7) in animplementation developed by BT known as the BT national user part orNUP. The SS7 signalling system is described in further detail in FrettenK G & Davies C G: “CCITT Signalling System No. 7; Overview”, BritishTelecommunications Eng J (April 1988).

[0018]FIG. 2 shows the architecture of the service control point and ofthe intelligent peripheral in further detail. The service control pointincludes a transaction server 51, an overload control server 52, and acommunications server 53. A card services platform 54 and an inboundservices advanced transaction server 55 are connected to the transactionserver 51. The connections between the card services platform, theinbound services advanced transaction server, the transaction server andthe communication server may all be by means of a broadband opticalfibre (FDDI) local area network. The connection between the transactionserver 51 and the overload control server 52 is by means of a so-calledmemory channel.

[0019]FIG. 3 illustrates how the memory channel is implemented betweentwo platforms such as the overload control server 52 and the transactionserver 51. Connections between the two platforms 51, 52 are configuredto simulate a common region of shared memory from which both platformscan read or write. Process virtual memory in one of the platforms isconnected to an input/output space that passes data out via the “write”memory channel via an external connection to the “read” memory channelof the other platform. From there it is written into the local RAM ofthe other platform.

[0020] Although in FIG. 2, only a single transaction server is shown, ingeneral the SCP includes a multiplicity of such transaction servers. Theoverload control server 52 maintains in a region of memory a table 521that records, for each of the transaction servers TCS1, TCS2 . . . acount of the number of calls in progress for each service application.

[0021] The service control point 5 is connected via a signalling pointrelay 21 to one or more of the service switching points 1.

[0022] Table 1 shows an example of the contents of the table 521 in theoverload control server. In this example, the table holds data for twoservices: a card service given reference number 0 and an inbound callingservice given reference number 1 . The first row of the table,referenced TCS0 holds the values for the maximum number of connectionsper service over all the transaction servers in the service controlpoint site. In this example, the values are 2000 for service 0 and 600for service 1. The subsequent rows then contain the counts for each ofthe transaction servers on the SCP site. Specifically, the counts arederived from the TCAP server of each transaction server. Counts areaccessed from the TCAP servers since it is aware of INAP messagesaffecting call state, and has knowledge of all calls to the intelligentperipheral.

[0023] In operation, the different services on the platforms 54 and 55both require use of the intelligent peripheral to gather data from thecustomer. In the case of the card services platform 54, the intelligentperipheral is used to acquire the customer account number from thecalling party. In the case of the inbound services server 55, theintelligent peripheral is used to present the calling party with a menuof choices, to enable appropriate routing of the call depending on theparticular needs of the calling customer. For both services, at therelevant points in the call, the relevant service platform returns anestablished temporary connection (ETC) request to the transactionserver. ETC requests from both platforms reference the same networkaddress for the IP, in this example 944271. When an ETC request isreceived from a particular service, for example service 0, then thetransaction server in conjunction with the overload control serverdetermines from the table storing the counts of ongoing connections tothe IP whether the limit for the particular service has been met. If, inthis example, the number of connections from service 0 to the IP, summedover all the different TCAP servers is less than the maximum value of2000, then the ETC request is admitted, the calling party is connectedto one of the free ports on the IP at address 944271, and the count forservice 0 and the respective TCAP server, for example TCS2 isincremented, e.g. from 17 to 18.

[0024]FIG. 4 shows in further detail the objects used in the overloadcontrol server 52 and the transaction server 51 in implementing theinvention. The diagram shows an object-oriented representation, in whichthe arrowed lines indicate signal flows between the different objects.In the transaction server, signals from an SS7 (common channelsignalling system number 7) interface and from the TCAP server TCS arepassed to an IP control (intelligent peripheral control) object. Signalsfrom the IP control are output via an OCSTCAP_interface (overloadcontrol server TCAP interface) and a resource manager into memorychannel memory. As described above, memory channel memory appears to becommon to the different platforms, including the OCS and TCS. However,the memory is not physically shared. Instead, writes to memory channelmemory are broadcast over an I/O (input/output) bus to all the machinesconnected to the memory channel. At the destination machines, they arewritten to physical memory which is then readable by attachedprocessors. In the OCS, the memory channel is connected to a resourcemanager and via the OCS management infrastructure to a memory channelOCS server. The functions implemented by these different objects willnow be described in further detail.

[0025] In a preferred implementation of the SCP known as NIP2, (NetworkIntelligence Platform 2), TCAP Server includes a rate-based adaptiveoverload control for IP. TCAP Server calls a function

[0026] bool IpControl::admitEtc (void)

[0027] before admitting an ETC to the network. If the function returnstrue, an ETC is sent; otherwise, no ETC is sent, and an ETC Fail is“faked” by TCAP Server and returned to the source of the ETC. Thecontrol is adaptive in response to ETC Fails sent from the network, andTCAP Server (actually the SS7_Interface class) calls a function

[0028] void IpControl::monitorEtcFail (void)

[0029] to inform the control of a received ETC Fail.

[0030] In another implementation known as NIP3, interaction with Voiceis subject to rate control which may be invoked in case of switch orcore transport network problems. Rate control in this case is notservice specific.

[0031] The implementation of software controlled limits for differentservices, termed “soft partitioning” is encapsulated in TCAP Server byenhancing the IpControl class. The decision on whether to admit an ETCis dependent on a Service Key which is passed to IpControl; also,IpControl polices the Voice IP network address to check that itcorresponds to the NIP site's local Voice IP set in a TCAP Serverconfiguration file. The new signature for admitEtc is

[0032] bool IpControl::admitEtc(const unsigned int serviceKey,

[0033] const INAP_BCD& address,

[0034] const char* const dialledNumber)

[0035] admitEtc( ) now checks both rate control and soft partitioningbefore agreeing to admit the ETC.

[0036] Various events may prevent or terminate the Voice IPinteraction—e.g ETC Fail, DisconnectForwardConnection, TCAP Abort, andpossibly others. The TCAP Server call context information is extendedwith a single flag to indicate that the call is interacting with theVoice IP. If this flag is set, and the TCAP Server receives anindication from the service or network side that the interaction isover, TCS code is responsible for calling a new function on IpControl:

[0037] void IpControl::ipInteractionEnded(const unsigned int serviceKey

[0038] and will clear the context flag indicating interaction with VoiceIP.

[0039] If the interaction was ended by an ETC Fail, TCS code also stillcalls monitorEtcFail( ) to allow adaptation of Voice IP rate control.

[0040] If IpControl rejects an ETC Fail due to Voice IP rate control ordue to soft partition limit, IpControl callsOCSTCAP_Interface::congestionNotify( ) with an appropriate rejectionreason. This requires the definition of the two new rejection reasons.If such rejections are sufficiently frequent, call gapping of theoffending service number may occur. This is the reason for the inclusionof the dialled number string in the parameters of admitEtc( ).

[0041] Extension to OCSTCAP Interface

[0042] This class is extended to encapsulate the TCAP Server's view ofcounts for soft partitioning held in Memory Channel. For NIP3 there is arequirement to maintain counts of Voice IP ports, per Service Key.

[0043] The system is designed to partition other resources in additionto the Voice IP. To permit this, the functions called onOCSTCAP_Interface will identify both a resource identifier and apartition identifier. The partition identifier may usually be equated toa Service Key

[0044] The OCS configuration file defines default partition sizesagainst the tuple of partition identifier and resource identifier. Italso defines the maximum available number of ports against each resourceidentifier. OCSTCAP_Interface will only accept function calls for softpartitioning which refer to those tuples of partition identifier andresource identifier which have been initialised by OCS.

[0045] The new member functions of OCSTCAP_Interface are:

[0046] bool admitCallToResource(const unsigned int resourceId,

[0047] const unsigned int partitionId,

[0048] bool& admitted)

[0049] bool removeCallFromResource(const unsigned int resourceId,

[0050] const unsigned int partitionId)

[0051] bool setMaximumForResource(const unsigned int resourceId,

[0052] const unsigned int partitionId,

[0053] const unsigned int maximum)

[0054] Here the return value indicates success or failure of thefunction call, e.g. if the function call refers to an uninitialisedresource it will fail.

[0055] admitCallToResource( ) checks the current calls in progress forthe resourceId/partitionId combination, and if it is less than thecurrently-set then it increments the count of current calls in progressand sets admitted to true.

[0056] removeCallFromResource( ) decrements the current calls inprogress for the resourceId/partitionId combination.

[0057] setMaximumForResource ( ) is used at TCAP Server startup time toset default local (per TCAP Server) values for partition sizes whichwill be used in the event that Memory Channel and the OCS areunavailable. Values supplied to setMaximumForResource( ) are obtained byIpControl from the TCAP Server configuration file.

[0058] ResourceManager Class

[0059] Within OCS code on both OCS and within TCAP Server, theResourceManager class encapsulates partition counts in Memory Channel onboth TCAP Server and OCS.

[0060] In principle, maintenance of an exact global count requires asingle count which is accessed atomically for increment and decrement bythe various TCAP Servers. However atomic increments and decrementsrequire locking. Use of Memory Channel locks is expensive, requiring atleast 2 Memory Channel write operations per lock cycle in addition tothe read/modify/write operation which is protected by the lock. Instead,in this preferred implementation, uses a count per TCAP Server. There isthen no need for locking, though all writes (for count increments anddecrements) must be written to Memory Channel to be accessible to TCAPServers on other TS boxes. The admitCallToResource( ) function then sumscounts of calls in progress over TCAP Servers (requiring only reads fromlocal memory) and compares with the total for the partition (alsobroadcast via Memory Channel but accessible with a local read) todetermine whether to admit the call.

[0061] This scheme results in a possibility of small transient errors inport counts (1 or 2 ports). In this application the effects of an errorare completely negligible. TABLE 1 0 1 2 31 TCSO 2000 600 (OCS) TCS1 1522 TCS2 17 25 12 19 TCS64 0 0

[0062] The key data structure for ResourceManager is the 2-dimensionalarray or “table” in shared memory described previously, with rowsindexed by TCAP Server identity and a column allocated to each uniquetuple of resource identifier and servivce identifier. Only two columnsare needed to manage the Voice IP ports for Inbound and Card, butsufficient columns are provided to allow for growth in the number ofservices and resources. Sparse resource identifier and serviceidentifier tuples will be mapped at startup to a dense set of columnindices. Linear search of the mapping will probably be simplest andfastest for the foreseeable number of resources and services.

[0063] Management of Soft Partitioning

[0064] Operations from M&C

[0065] M&C (management and control) screens in a network embodying theinvention may display a screen specific to the peripheral, in this caseVoice IP, with rows indexed by TCAP Server identifier and columnsindexed by service friendly name, initially just Inbound and Card. Cellsin this table will show current active connections to Voice IP from eachTCAP Server for each service. M&C will also show the total number ofVoice IP ports configured as available, the total ports configured asavailable to each service, and the total of ports not configured to anyservice. This data will be obtained over the M&C Object Broker interfaceto OCS using remote method invocations which are logically equivalent tothe following member function signatures (note that there will only beone resourceId, referring to VoiceIP, in NIP3)

[0066] bool setTotalForResourceAndService(const unsigned int resourceId,

[0067] const unsigned int serviceId,

[0068] const unsigned int total)

[0069] Used to set a partition size on a specific resource.

[0070] bool getTotalForResourceAndService(const unsigned int resourceId,

[0071] const unsigned int serviceId,

[0072] unsigned int& total)

[0073] Used to query a partition size (particularly at startup whenpartition sizes are set by OCS from its configuration file).

[0074] bool zeroCountsForResourceAndService(const unsigned intresourceId,

[0075] const unsigned int serviceId,

[0076] const unsigned int tcsId)

[0077] Used to zero the counts for a specific partition in the eventthat the count has drifted away from true calls in progress.

[0078] bool getTotalForResource(const unsigned int resourceId)

[0079] Used to get total ports configured as available on a specificresource.

[0080] bool getCountsForResourceAndService(const unsigned intresourceId,

[0081] const unsigned int serviceId,

[0082] const unsigned int tcsId,

[0083] unsigned int& count)

[0084] Used to get counts of active connections for each resource,service, and TCAP Server.

[0085] Display of Rejection Counts Due to Soft Partitioning

[0086] Use of the OCS congestionNotify( ) mechanism will ensure displayof rejection counts on the standard M&C screen for OCS rejection stats

[0087] Alarms

[0088] OCS will raise 2 new alarms per service/resource tuple: an “amberalert” when connections for the partition exceeds a fraction f1 of theconfigured maximum, cleared when connections drop below f2 of themaximum; and a “red alert” when connections for the partition exceeds afraction f3 of the configured maximum, cleared when connections dropbelow f4 of the maximum. OCS will raise or clear these alarms as aresult of a frequent scheduled check( ) function called on theResourceManager object.

[0089] Other alarms related to low-level problems will also be defined.

[0090] Configuration

[0091] On TCS—configured maxima per resource-service tuple, per TCAPServer, for use if OCS is unavailable.

[0092] On OCS—configured maxima per resource-service tuple, for thewhole site; configured total of available ports per resource;configurable number of columns for resource-service tuples

[0093] On M&C—mapping of service key (used as service identifier) toservice friendly name

[0094] As described above, the function admitCallToResource ( ) is usedto determine whether a new request to establish a connection with theresource platform is to be admitted. In the example described above, therequest is simply refused if the limit for the particular service hasbeen reached. In an alternative embodiment, one service is allowed toborrow resource from another service, provided that the overall capacityof the resource platform is sufficient. This is illustrated in the flowdiagram of FIG. 5, which shows the steps implemented by theadmitCallToResource( )function in this case. As before, when an ETCrequest is received for service x (step 1) the total number of calls forx over all servers is determined (step 2) and compared with the maximum(step 3). If the maximum is not yet reached then the request is admitted(step 5) and the count incremented. If the service maximum is reached,then the total number of calls for the other service, service y, isdetermined. If the total for service y falls below the maximum forservice y by more than a predetermined amount (step 6) the service xcall is admitted and the count for service x incremented. The port“borrowed” from service y is released by service x as soon as the callis completed.

1. A method of operating a communications network including a pluralityof network switches, a service platform connected by a signallinginterface to the plurality of network switches, and a service resourceplatform, the method including: when a service provisioned for a partyto a call requires service resources from the service resource platformthen, under the control of the service platform, connecting a party tothe call via a network switch to the service resource platform; for eachof a plurality of different services requiring the service resources ofthe service resource platform, maintaining a count of the respectivenumber of ongoing calls connected to the service resource platform;storing for one or more of the plurality of services a maximum countvalue; and connecting a further call to the service resource platformwhen the count value for the said service is less than the maximum countvalue.
 2. A method according to claim 1, in which the service resourceplatform has a single network address and a plurality of portsassociated with the said single network address, and a common range ofports are accessed by the plurality of services.
 3. A method accordingto claim 1 or 2, including storing the said count of the respectivenumber of ongoing calls connected to the service resource platform foreach of the plurality of different services in an overload controlserver connected to the service platform.
 4. A method according to anyone of the preceding claims, in which the service platform includes aplurality of transaction servers and in which, in the step ofmaintaining a count, a separate count is maintained, for each service,for each of the plurality of transaction servers.